1. Progressive Enhancement

   Content is king; make sure it loads above all else. Then make it visually approachable. Then make it interactive.
2. Reusability

   Build patterns to make coding easy and brand consistency will happen automatically.
3. Responsive Design

   Start by thinking about smaller screens, and grow from there. Be responsive, create adaptively.
4. Prototyping

   The best way to see how a design works is to build it.
5. Communicating

   Not sure what pattern to use? Need a new pattern? Something doesn't seem quite right? Let's talk about it!
6. Technique

   Consistency isn't just for branding. Adhering to coding standards can help everyone.

Writing the code for beautiful designs and interactions is fun, but in the end people visit most sites to gain information. In this light, it is key that the information given by a page is accessible to a wide audience and not hidden behind fancy styles and javascript. You can never have 100% control over the client's abilities, and so it is important to deliver content from the ground up with a strong foundation. If nothing else renders but HTML, it will still be readable, accessible and functional if semantic HTML is used.

There is an assumption with many people that progressive enhancement means you aren't allowed to do the fun stuff, too. This is not true! The important thing to remember is that you are starting with a strong foundation on which to build upon. Once you have that, it is much easier to work with css and javascript, because you have the node structure created already. All you need is to consider the amount of time required to create each layer.

What to Consider:

• Which parts are absolutely necessary for the end user?
• Which are pure design choices?
• Can performance be enhanced by moving some things to the back end?
• Am I using HTML elements that make sense for the content inside of them?

Reusability is all about efficiency, and is one of the main reasons we have created this library. It means that we can always be sure what something will look like. It means that we maintain branding consistency. It means that we can make needed changes in one place, and all of our properties will be updated.

It also means that our front end code is easy to use, for developers and non-developers alike. A dev who needs to add a certain component can simply copy and paste the code into their application. A business representative who wants to know what their content will look like can simply look at an example to get an immediate idea of what to expect.

Because we are always updating and changing, this component library is a living document and sometimes we will need to create new patterns. When developing interfaces, have an eye towards reuse. Unless the use case warrants a new pattern or collection of fields strive to use the same markup across applications in such a way where an update to the pattern only needs to be made once.

What to Consider:

• Have I seen something like this before?
• Can we use an existing pattern to do this?
• Where else could we use this new pattern?

We can't predict what devices or input types our stakeholders will want to use to interact with our interfaces, so we support all devices and input types (keyboard, touch, mouse). Because mobile devices are growing as a primary interface across the world, we use the mobile-first approach to streamline layouts and tasks.

Planning for a small screen and assuming the components will expand to fit can make development easier. Often times a component coded for a small screen will look just as good on desktop sizes. It also means that by default, we'll have a decent layout even for older browsers. We aim to support all browsers, but we optimize for the most recent versions.

Additionally, by writing semantic code and styling for minimal devices, we help ensure that we meet accessibility guidelines. HTML supports content by providing context. Styling supports that content by giving it visual context, and we use relative units, particularly "rems" to make sure that no matter the screen size or zoom everything fits as intended. All functionality should be achievable without the need for javascript, which may not be accessible with some devices or in some locations.

What to Consider:

• Does this design take into account smaller devices?
• Is my HTML semantic?
• Does my code pass accessibility standards?
• Have I tested my code in multiple browsers and devices?

Rather than depend solely on static images, wireframes and written documentation to determine how a component should be built, we prefer to prototype as much as possible. While imagery is a good start, it is easier to understand the limitations and effects of what we can do with functional code. Particularly with non-developers, having a hands-on demonstrable piece of work helps to show technical limitations visually.

Creating prototypes also helps to speed up work. After creating something basic, you have already created the foundation of the component. Even if tweaks are needed, with a prototype already made it is easy to put that code into place.

Prototyping can be done in many environments. Creating something in an existing code repository would be an obvious choice, because it will already be connected to our library. However, creating something from scratch in Notepad or even just adjusting styles live in a browser's dev tools can be useful ways to demonstrate requested changes and their effects on other page components.

What to Consider:

• Will creating a prototype help illustrate the problem?
• What requirements need to be completed?
• What resources will a proof of concept require?
• Is my code testable?

Because front end code is what drives the visual aspects of our web properties, it is often the most commented on for desired changes and updates. Because of this, we need to be able to communicate well not only with other developers but with business partners and our user base to better understand their needs and to explain our reasonings. We also do our best to keep in contact with other teams to stay on top of updates and future work, to help make better solutions and estimates of time required to deliver.

It is also common that new developers or developers unfamiliar with fron end code will have a need to use our work. In that vein it is important that we document as much as possible. We have tried to make this library a useful tool for everyone in the business to use in one way or another. It is also important to us that our code is readable and understandable, and so writing clearly and using helpful comments in code is key.

Finally, because the component library is our source for all styling and scripting and front end is a "shared service", it is important to make everyone aware when changes are coming. Nobody likes to be surprised at an inopportune time. We are all part of the same team, so let's work together as much as possible!

What to Consider:

• Have I made my changes clear to all teams?
• Have I communicated any red flags?
• Does my code include readable comments?
• Is my component documented in the library?

In addition to commenting, we try to adhere to a few other coding standards as well. This helps ensure that code is consistent from one team to the other, and helps to unify everything into a single entity. Here are some things to look for:

HTML

• HTML elements should make sense with the content they contain.
• HTML should never be used solely for layout.
• Element names and attributes should be written in lower case.
• Use aria attributes where necessary for accessibility, but know that they are not always needed.
• ID's should be used when a unique link or javascript connection needs to be made. They should be written "inCamelCase"
• Classes should be used for styling, less often as javascript hooks. They should be written in lower case.

CSS

• CSS is powerful, use it wherever possible in favor of javascript.
• Avoid targeting elements specifically. Use classes wherever possible.
• Class names should be meaningful to their purpose.
• When writing large batches of rules, alphabetize the rules for easy findability.
• When using SASS, don't nest more than two levels in.

JavaScript

• Write as little code as possible.
• Write as many comments as necessary.
• Target nodes via their ID if possible.
• Avoid using third party plugins whenever possible.
• Test test test!

General

• Indent your code for readability.
• Add comments to clarify your code.

But you should strive for it anyway, and don't be afraid to ask for help!